The design system nobody used

It was, by every measure we had chosen for ourselves, a success. Three hundred and forty components. Full token coverage. A documentation site with live examples and a contribution guide written in the second person. Two engineers on it full time for fourteen months.

Adoption, when someone finally measured it, was under a fifth of the surfaces it was built for. The product teams had quietly kept their own buttons.

Why they kept their own buttons

I sat with four of them and asked. Nobody said the components were bad. Every answer was some version of the same sentence: using it costs me a conversation.

The button was fine until the day a page needed one that was slightly wider. Then the path forward was to open an issue, wait, discuss the principle, and land a change that touched every surface in the company. Copying the button into the feature folder took forty seconds and blocked nobody. Given a deadline, everyone chose the forty seconds. They were right to.

We had optimised for the wrong scarcity. We thought the expensive thing was inconsistency. The expensive thing was permission.

What we changed

We cut the library to 40 components — the ones nobody ever wanted to vary — and made every one of them accept an escape hatch. Then we wrote down, in one paragraph on the front page, that copying a component out of the library and editing it was allowed and expected, and that if two teams did it the same way we would pull it back in.

Adoption is around eighty percent now. The library got smaller and more of it gets used, which sounds like a paradox and is not. A component that cannot be varied is not a component, it is a rule with a nice API. Rules need enforcement. Components need to be easier than the alternative, and there is always an alternative, and it is always forty seconds long.